ci: extend go1.26.4 pin to remaining test workflows (follow-up to #5056)#5066
Conversation
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 7007b07 | Docs | Datadog PR Page | Give us feedback! |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f2b2ce03fe
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6.5.0 | ||
| with: | ||
| go-version: stable | ||
| go-version: "1.26.4" |
There was a problem hiding this comment.
Pinning this setup step does not pin the Orchestrion integration-test matrix: the next step runs go run ./internal/orchestrion/matrix, whose output is still oldstable/stable (internal/orchestrion/matrix/matrix.go:51), and integration-test uses that output as matrix.go-version (.github/workflows/orchestrion.yml:120). Per the setup-go docs, stable tracks the latest stable Go, currently 1.26.5, so these jobs will still run the unpinned patch rather than 1.26.4; change the matrix output while this pin is needed.
Useful? React with 👍 / 👎.
| strategy: | ||
| matrix: | ||
| go-version: [ "1.25", "1.26" ] | ||
| go-version: [ "1.25", "1.26.4" ] |
There was a problem hiding this comment.
This pinned PR leg still invokes unit-integration-tests.yml, whose prerequisite set-up job installs go-version: stable before computing the contrib matrix (.github/workflows/unit-integration-tests.yml:47-56). Because setup-go resolves stable to the latest stable patch, currently 1.26.5, PR/main/dynamic workflows can still fail in this setup phase under the patch this change is trying to avoid; pass the requested Go version into that setup step as well.
Useful? React with 👍 / 👎.
| - uses: actions/setup-go@924ae3a1cded613372ab5595356fb5720e22ba16 # v6.5.0 | ||
| with: | ||
| go-version: stable | ||
| go-version: "1.26.4" |
There was a problem hiding this comment.
When the AppSec module cache has already been populated by a pre-pin run, this job will still reuse it: the cache key is only go-pkg-mod-${{ hashFiles('**/go.sum') }}, and the lookup-only hit skips re-downloading before the test jobs restore that same cache. Since this pin is meant to avoid Go 1.26.5 module-cache corruption, leaving the key unchanged means a corrupted 1.26.5 cache can continue to break AppSec CI even though this step installs 1.26.4; include the Go patch/toolchain in the cache key or force a one-time cache refresh.
Useful? React with 👍 / 👎.
#5056 pinned Go 1.26.4 (off corruption-prone 1.26.5, golang/go#77168) only in smoke-tests.yml and govulncheck-fix.yml. The remaining test/build workflows still ran 1.26.5 via stable or the "1.26" minor, so the same zip: checksum error corruption kept hitting the default-branch and PR test matrix. Pin the 1.26.5-exposed go-version entries to "1.26.4" in main-branch-tests, pull-request, appsec, dynamic-checks, and orchestrion; oldstable and "1.25" unchanged. govulncheck.yml stays on stable on purpose: govulncheck scans the toolchain stdlib, and 1.26.4 still carries GO-2026-5856 (crypto/tls ECH, CVE-2026-42505, fixed in 1.26.5), so pinning it down reintroduces a real finding. Test/build jobs only need to dodge the corruption, so 1.26.4 is fine there. On smoke-tests the pin cut the corruption rate from ~40% to ~10% -- a reduction, not a fix. Temporary until Go ships the #77168 fix.
f2b2ce0 to
7007b07
Compare
BenchmarksBenchmark execution time: 2026-07-24 11:56:28 Comparing candidate commit 7007b07 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 326 metrics, 0 unstable metrics, 1 flaky benchmarks without significant changes.
|
2 participants
What does this PR do?
Follow-up to #5056, which pinned Go 1.26.4 (off corruption-prone 1.26.5,
golang/go#77168) but only insmoke-tests.yml+govulncheck-fix.yml. The remaining test/build workflows still ran 1.26.5 viastable/"1.26", so the samezip: checksum errorkept hitting the default-branch and PR test matrix.Extends
"1.26.4"to the test/build workflows still exposed:main-branch-tests.yml— the default-branch test driverpull-request.ymlappsec.yml— macOS + container matrices and twostablejobs (the container matrix also feeds thegolang:1.26.x-*image tags)dynamic-checks.ymlorchestrion.ymloldstable(1.25.x) and"1.25"entries are unchanged.govulncheck.ymlis deliberately left onstable. govulncheck scans the toolchain's stdlib, and 1.26.4 still carries GO-2026-5856 (crypto/tls ECH, CVE-2026-42505, fixed in 1.26.5) — pinning it down reintroduces a real finding. Test/build jobs only need to dodge the corruption, so 1.26.4 is fine for them; the vulnerability scanner has to stay on the latest patch.Data
On
smoke-tests.yml(pinned by #5056), the corruption rate dropped from roughly 40% of runs on 1.26.5 to about 10% on 1.26.4 — a reduction, not a fix. 1.26.4 still fails occasionally (e.g. the 2026-07-24 smoke nightly). The residual is expected until Go ships the #77168 fix in a later 1.26.x.Motivation
Reduce default-branch and PR CI flakiness (incident #57895) by removing the remaining exposure to the go1.26.5 build/module-cache corruption. This is temporary: revert to
stable/"1.26"once a fixed Go release is out. CI-only; no code or go.mod changes. Verified withactionlint.